System and method for maintaining security in a distributed computer network

ABSTRACT

A system for maintaining security in a distributed computing environment comprises a policy manager located on a server to maintain policy data files and distribute local security policies to a plurality of clients, and a plurality of application guards, wherein each application guard is located at one of the plurality of clients to manage access by individual transactions to at least one application associated with the application guard, wherein the application guard controls access to the application based on a local security policy received from the policy manager.

CLAIM OF PRIORITY

This application is a continuation of U.S. patent application Ser. No.09/721,557, filed Nov. 22, 2000, entitled SYSTEM AND METHOD FORMAINTAINING SECURITY IN A DISTRIBUTED COMPUTER NETWORK, which is acontinuation of U.S. patent application Ser. No. 09/248,788, filed Feb.21, 1999, now U.S. Pat. No. 6,158,010, issued Dec. 5, 2000, entitledSYSTEM AND METHOD FOR MAINTAINING SECURITY IN A DISTRIBUTED COMPUTERNETWORK which claims the benefit of priority to U.S. Provisional PatentApplication No. 60/105,963, filed Oct. 28, 1998, entitled SYSTEM ANDMETHOD FOR MAINTAINING SECURITY IN A DISTRIBUTED COMPUTER NETWORK, eachof which applications are herein incorporated by reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computer security systems, andrelates more particularly to a system and method for managing andenforcing complex security requirements in a distributed computernetwork.

2. Description of the Background Art

Computer security issues have become more complex with the continualevolution of contemporary computer systems. As corporations utilizeincreasingly distributed and open computing environments, the securityrequirements of an enterprise typically grow accordingly. The complexityof employee, customer and partner access to critical information assets,while assuring proper security, has proven to be a major hurdle. Forexample, many organizations deploy applications that allow theirexternal business partners, as well as their own internal employees, toaccess sensitive information resources within the enterprise. In theabsence of adequate security measures, an enterprise may thus be subjectto the risk of decreased security and confidentiality.

While most organizations focus their security concerns on protecting theinternal network from the outside world, it is estimated that 80-90% ofall corporate security breaches come from within an organization(source: Aberdeen Group, September 1997). This further underscores theneed to specify and enforce an access control security policy within theenterprise network.

In today's complex business environment, specifying, stating,implementing and managing an enterprise access control policy may beboth difficult and inefficient. When corporate data and applicationsrevolved around a mainframe model, the problem of defining and managingaccess to corporate applications was relatively straightforward. Today,the complexity of business methods, as well as the complexity ofdistributed application architectures, may force companies to resort tomanual, ineffective or highly custom approaches to access control intheir attempts to implement the business process.

To secure a complex and distributed computer system, the system maytypically employ a combination of encryption, authentication, andauthorization technologies. Encryption is a means of sending informationbetween participants in a manner that prevents other parties fromreading the information. Authentication is a process of verifying aparty's identity. Authorization is a technique for determining whatactions a participant is allowed to perform.

Encryption and authentication are well-understood and have led toeffective network security products, whereas authorization technology isnot as well developed, and is often inadequate for many enterprises. Thesecurity approach of most companies today is to focus on theauthentication of users to ensure that those users are part of theorganization or a member of a select group. Authentication can beaccomplished with a number of different approaches, from simple passwordor challenge response mechanisms to smart cards and biometric devicessuch as a fingerprint reader. Once users are authenticated, however,there is still a significant problem in managing and enforcing their setof privileges, which may be unique and vary widely between users. Thesame authentication mechanism can be used for every user, but differentauthorization mechanisms must be developed for most applications.Therefore, reliable and efficient access control is a much moredifficult problem facing enterprises today.

Authentication mechanisms often work together with some sort of accesscontrol facility that can protect information resources fromunauthorized users. Examples of network security products includefirewalls, digital certificates, virtual private networks, and singlesign-on systems. Some of these products provide limited support forresource-level authorization. For example, a firewall can screen accessrequests to an application or a database, but does not provideobject-level authorization within an application or database. SingleSign-On (SSO) products, for example, maintain a list of resources anauthenticated user can access by managing the login process to manydifferent applications. However, firewalls, SSO and other relatedproducts are very limited in their ability to implement a sophisticatedsecurity policy characteristic of many of today's enterprises. They arelimited to attempting to manage access at a login, or “launch level”,which is an all or nothing approach that inherently cannot implement abusiness-level policy.

A real-world security policy within a large enterprise is a detailed anddynamic knowledge base specific to that organization. The authorizationprivileges are specific to the constantly evolving set of users,applications, partners, and global policies that the enterprise puts inplace to protect its key information resources. A security policy withina large enterprise can consist of tens or hundreds of thousands ofindividual rules that cover which users are authorized to accessparticular applications, perform various operations, or manage thedelegation and transfer of tasks. Many of these policy rules thatimplement the business practice of the organization have to be hardcoded within custom-built applications or stored in the database.

The key problem is that these policy rules are localized, scatteredthroughout the organization, and embedded in applications and databases.Such embedding is expensive and error-prone, and mitigates againstefficient policy updates. An organization cannot effectively implementand manage the resulting policy. Inconsistencies arise and updates canquickly become unmanageable. Policy queries and analysis from a globalperspective are nearly impossible. The resulting policy begins todiverge from the intended business practices of the organization.Compromises are made in the policy implementation at the departmentlevel, and auditors can quickly become frustrated.

The increasing security risks associated with the proliferation ofdistributed computing, including Intranet and Extranet applications, areprompting many organizations to explore a broad range of securitysolutions for controlling access to their important information assets.Although organizations have a number of solutions to choose from forauthenticating users (determining and verifying who is attempting togain access to the network or individual applications), there is littlechoice when it comes to controlling what users can do and when they cando it to the extent necessary to implement the kinds of complex securitypolicies required by modern organizations. Organizations have beenforced to choose between custom authorization solutions that are costly,error-prone, and difficult to manage, or third-party solutions that arevery limited in their ability to control access to information acrossapplications and databases.

A real-world security policy within a large organization is a detailedand dynamic knowledge base that determines which users are authorized toaccess particular applications, perform various operations or manage thedelegation and transfer of tasks, as well as when and under whatcircumstances they are permitted to do so. Authorization privilegesdepend upon a constantly evolving set of users, applications, partners,and business polices that comprise the enterprise security policy. Atypical enterprise environment consists of several thousand users,hundreds of applications, and a myriad of network resources, resultingin a security policy that can consist of tens or hundreds of thousandsof interrelated policy rules.

Typically, organizations attempt to control access to the internals ofin-house applications through policy rules that are hard-coded in theapplication or through stored procedure statements in the database. Butas the number of applications and databases grows, this patchworkapproach to authorization quickly gets out of hand. First, organizationsmust incur the costly and time-consuming overhead of developingcustomized security code for each application. But more importantly,once the code is developed and embedded in an application, the embeddedpolicy rules become impossible to track, difficult to update, and nearlyimpossible to manage because they are scattered throughout theorganization.

With an estimated 80 percent of all security breaches coming fromauthorized users (source: Forrester Research), advanced policy featuresand enforcement mechanisms are needed to control access to sensitiveinformation assets. To implement an enterprise policy, organizationsneed a centralized policy and a powerful way to specify policy rules togive them adequate access control security. At the same time, they needa distributed authorization infrastructure to provide authorizationservices to all applications with performance and scalability for moderndistributed network environments.

Therefore, for the foregoing reasons, an improved system and method areneeded to protect the distributed networks of enterprises againstunauthorized access to their valuable information assets by managing andenforcing the complex security policy requirements of the organization.

SUMMARY OF THE INVENTION

In accordance with the present invention, a system and method aredisclosed to manage and enforce complex security requirements for acomputer system in a distributed computer network.

It is therefore an object of the present invention to provide an accesscontrol system that can manage individual transactions by users aroundwell-defined, detailed objects within an application. It is also anobject of the present invention to provide a policy manager that enablesthe creation, modification, querying, and analysis of an enterpriseaccess-control policy, as well as the configuration and monitoring ofintegrated audit logs, while delivering the performance and scalabilityrequired to meet the demands of any enterprise. It is a further objectof the present invention to provide a system that combines a centrallymanaged policy database with distributed authorization (access control)services that enforce the policy for all applications across theorganization.

It is also an object of this invention to provide a system that works inconjunction with any authentication system, including digitalcertificates and smartcards, and obviates the need for single sign-onsystems by letting organizations set detailed, dynamic rules for exactlywho can access which applications, databases, and other network objects.It is a still further object of this invention to provide a robustsecurity policy and authorization service that can be implemented invery heterogeneous environments, across all applications and databaseswithin the organization, thereby completely eliminating the need forembedded, custom security code within applications, and making itpossible to centrally manage and administer a consistent, robustsecurity policy for all applications, databases, and network resources.Furthermore, organizations would no longer have to rely on authorizationmechanisms provided by packaged or web application vendors that do notintegrate with in-house or other third-party products.

In the preferred embodiment, the system comprises a policy managerlocated on a server for managing and distributing a local client policybased on a global security policy, and an application guard located on aclient or server associated with one or more clients for managing accessto securable components as specified by the local client policy. Theglobal policy specifies access privileges of the user to securablecomponents. The policy manager may then distribute a local client policybased on the global policy to the client or server. An application guardlocated on the client or server then manages authorization requests tothe securable components as specified by the local client policy. Eachauthorization request may be recorded in an audit log to keep track ofthe authorization requests, whether they were granted or denied, andother useful information.

The system and method of the present invention supports centralizedmanagement and distributed authorization. A central policy server storesand manages the policy rules in a centrally administered database. Apowerful graphical user interface is used to create, manage, andcustomize the elements of a policy. Security rules can be specified byboth novice and expert users. A dedicated authorization service isassociated with one or more applications. The central policy serverautomatically distributes (over the network) only the relevant portionof the enterprise policy to each remote service. This distributedarchitecture ensures that authorization requests are not bottlenecked ata central service point and provides unlimited scalability and maximumperformance, regardless of the number of applications or policy rulesinvolved.

A more sophisticated security policy is possible because the applicationhas the ability to evaluate access privileges upon every access to theinformation, during every transaction, and at every data request.

Therefore, the present invention more efficiently and effectivelymanages and protects computer applications, databases, and networkresources against unauthorized access in a distributed computer network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of one embodiment for one system, inaccordance with the present invention;

FIG. 2 is a block diagram of one embodiment of the non-volatile memorylocated within the server in FIG. 1, according to the present invention;

FIG. 3 is a block diagram of one embodiment of the non-volatile memorylocated within the client in FIG. 1, according to the present invention;

FIG. 4 is a block diagram of one embodiment of the policy managerlocated within the non-volatile memory in FIG. 2, in accordance with thepresent invention;

FIG. 5 is a block diagram of one embodiment of the application guardlocated within the non-volatile memory in FIG. 3, according to thepresent invention;

FIG. 6 is a block diagram of one embodiment of a policy loader, inaccordance with the present invention;

FIG. 7 is a flowchart of one embodiment of method steps to configure asystem, in accordance with the present invention;

FIG. 8 is a flowchart of one embodiment to manage policy in themanagement station, according to the present invention;

FIG. 9 is a flowchart of one embodiment to navigate tree in themanagement station, according to the present invention;

FIG. 10 is a flowchart of one embodiment to analyze policy in themanagement station, in accordance with the present invention;

FIG. 11 is a flowchart of one embodiment to edit policy in themanagement station, in accordance with the present invention;

FIG. 12 is a flowchart of method steps to distribute policy, accordingto one embodiment of the present invention;

FIG. 13 is a flowchart of method steps for client access authorization,in accordance with one embodiment of the present invention; and

FIG. 14 is a flowchart of method steps to evaluate authorizationrequest, according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention relates to an improvement in security techniquesto protect computer systems against unauthorized access. The followingdescription is presented to enable one of ordinary skill in the art tomake and use the invention and is provided in the context of a patentapplication and its requirements. Various modifications to the preferredembodiment will be readily apparent to those skilled in the art and thegeneric principles herein may be applied to other embodiments. Thus, thepresent invention is not intended to be limited to the embodiment shownbut is to be accorded the widest scope consistent with the principlesand features described herein.

The present invention includes a system and method for managing andenforcing complex security requirements in a distributed computernetwork, and comprises a policy manager located on a server for managingand distributing a policy to a client, and an application guard locatedon the client, the application guard acting to grant or deny access tovarious components of the client, as specified by the policy.

Referring now to FIG. 1, a block diagram of one embodiment of adistributed computer network system 110 is shown, including a server 112connected via a network 114 to a client 116, in accordance with thepresent invention. One client 116 is shown, but server 112 is typicallyconnected to many clients 116. In the FIG. 1 embodiment, server 112 maypreferably include a central processing unit (CPU) 118, a read-onlymemory (ROM) 120, a random-access memory (RAM) 122, a non-volatilememory 124, an input device 126, and a display 128 all connected via abus 130.

Similarly client 116 may preferably include a central processing unit(CPU) 132, a read-only memory (ROM) 134, a random-access memory (RAM)136, a non-volatile memory 138, an input device 140, and a display 142all connected via a bus 144.

Server 112 preferably contains a program stored in non-volatile memory124 for managing a policy or a set of rules and then distributing thepolicy to client 116 via link 114. Client 116 preferably contains aprogram stored in non-volatile memory 138 for granting or denying accessto various components or resources of client 116, as specified by thepolicy distributed from server 112. For example, various components orresources of client 116 can include applications, functions orprocedures within an application, data structures within an application,and database or file system objects referenced by an application.

Referring now to FIG. 2, a block diagram of one embodiment fornon-volatile memory 124, located within server 112 of FIG. 1, is shown.In the FIG. 2 embodiment, non-volatile memory 124 includes a policymanager 210 that manages and distributes a policy. A policy is intendedto specify the security requirements for applications and databaseobjects. A policy may contain thousands of “security rules” thatdescribe several constraints, including what applications a particularuser can access, what objects (operations) within an application a usercan access, and how those privileges are constrained by time, geography,or external events. In general, a policy or authorization policy shouldconstrain access to both applications and the operations within them.The policy may be generalized to groups and hierarchies, not justspecified for individual users. This would greatly improve manageabilityand lead to more comprehensible, business-level policies.

An authorization policy preferably consists of four components,including objects, subjects, privileges, and conditions. Objects may beapplications, or the operations within an application. Examples ofobjects include applications or methods, web pages, database tables orfiles, and menu items in a graphical user interface. The granularity ofobjects has a direct impact on the level of security achieved. The lessinformation an object contains, it is less likely that a user has accessto information not needed to perform his job function. On the otherhand, the granularity of objects should be balanced against the ease ofsecurity management. The more information an object contains, the fewerobjects that have to be protected, and the smaller the policy is.

Objects are preferably organized into an object hierarchy. If an objectrepresents an application, then its children objects might represent themethods with the application. Similarly, if an object represents adatabase, then its children objects might represent the tables and viewswithin the database.

If a user is granted a certain privilege on a parent object, then he isautomatically granted the privilege on all the children objects.Similarly, if a user is denied a certain privilege on a parent object,then he is automatically denied the privilege on all the childrenobjects. In other words, privileges are inherited from parent tochildren objects. Privilege inheritance through the object hierarchyeases security management because rather than granting the sameprivilege to every child object, the privilege is granted once to theparent object, and if the privileges of an object change, the policy onall the children objects automatically reflect the changes made to theobject.

Subjects may be users, or roles containing users, who access protectedobjects. Subjects correspond to users that have access to information ina system. Users can either be internal or external to a system. Usersare authorized to access information in order to perform their jobfunctions. Such access may be controlled so that a user gets access onlyto the information needed to perform his job function.

An object, such as an application or a database, typically has its ownlist of users. These are users who can log on to the object and beauthenticated by the objects, sometimes through an externalauthentication server. In a large system, users are preferablymaintained separately by one or more directory servers. Users arepreferably extracted from objects or directory servers, and aremaintained up-to-date by synchronizing with these objects and directoryservers.

Alias users may also be supported. An alias of a user is another userwho inherits all the privileges of the user under certain conditions.Alias facilitates authorization management by providing fine granularityof control on the propagation of privileges. For example, an alias of auser can be created to perform his job function while he is absent. Theinheritance of privileges takes effect only when the user is absent. Analias implements the business requirements of delegation, where theprivileges of a user can be delegated to another user under certainconditions. Conditional inheritance of privileges through an aliasreduces the burden of security management, because it restrictsprivilege propagation to situations when certain conditions aresatisfied.

Users of an object may be defined as being local to that object. In atypical system, the same user is often represented by different loginidentifications in different objects. This system may support the notionof a “global” user to capture this situation. Every global user ismapped to a set of local users, one per object. Global users facilitatethe centralized management of users throughout the system, even if theyare identified by different names in different objects.

A privilege defines the kinds of access that may be allowed on objects.In the preferred embodiment, a privilege is the right to perform aparticular action on a specific object. The kinds of privileges thatapply to an object depend on the type of the object. Examples ofprivileges include the right to execute an application, the right todownload a web page, the right to query a database table, or the rightto view a menu item.

Privileges are granted to users so they can accomplish tasks requiredfor their job. A privilege should be granted to a user only when it isabsolutely required for the user to accomplish a task. Excessivegranting of unnecessary privileges may lead to compromised security. Auser may receive a privilege in two different ways, privileges can begranted to users explicitly (for example, user SMITH can be granted theprivilege to execute the payroll application), or privileges can begranted to a role (a named group of privileges), which is then grantedto one or more users (for example, a role named “clerk” can be grantedthe privilege to execute the payroll application, and user SMITH can begranted the clerk role).

Roles are named groups of privileges that are granted to users or otherroles. Users granted to a role are the members of that role. A role isoften used to represent the set of privileges needed to perform a jobfunction.

The members of a role automatically inherit all the privileges grantedor denied to the role. In addition, roles may be organized into a rolehierarchy, where parent roles are granted to children roles. If a parentrole is granted a privilege, then the children roles are automaticallygranted the privilege. Similarly, if a role is denied a privilege, thenthe children roles are automatically denied the privilege.

Roles of an object may be defined as being local to that object. In atypical system, the same role is often represented by different names indifferent objects. This system may support the notion of a “global” roleto capture this situation. Every global role is mapped to a set of localroles, one per object. Global roles facilitate the centralizedmanagement of roles throughout the system, even if they are identifiedby different names in different objects.

Role membership may be further constrained by the notion of mutualexclusion. Two roles are mutually exclusive if no single user can begranted to both roles simultaneously. Role mutual exclusion implements abusiness requirement of separation of duty. For example, asubmit.sub.—budget role and an approve.sub.—budget role should bemutually exclusive, because no user should be simultaneously authorizedto perform both actions.

In a typical policy, there are preferably two types of access rules, agrant rule, and a deny rule. A grant rule states that a privilege on anobject is granted to a subject under an optional constraint. A deny rulestates that a privilege on an object is denied to a subject under anoptional constraint. Additionally, a wild card “any” may be used as aprivilege, object, or subject, meaning that any legitimate value couldbe substituted in its place.

An access request preferably consists of a privilege, an object, and asubject, representing the fact that the subject request authorization ofthe privilege on the object. An access request matches a grant rule ifthe privilege, object, and subject math those in the rule, and theconstraint in the rule evaluates to “true.” An access request matches adeny rule if the privilege, object, and subject match those in the rule,and the constraint in the rule does not evaluate to “false.”

An access request is denied if there is a deny rule matching therequest, or there are no access rules matching the request. An accessrequest is granted if there are no deny rules matching the request, andthere is a grant rule matching the request.

Conditions define the constraints on when objects and subjects can beaccessed. The constraints in an access rule specifies furtherrequirements on when the access rule is applicable. These requirementscould be conditioned on properties of the object or the subject.

Constraints are preferably expressions formed from conditions andBoolean operators NOT, AND, and OR. Three kinds of built-in conditionsmay be used: 1) relational operations =, < >, <, <=, >, >= on integers;2) relational operations =, < >, LIKE, NOTLIKE on strings (the operatorLIKE takes a string and a pattern and evaluates to true if the stringmatches the pattern, the operator NOTLIKE is the negation of LIKE); and3) set operations IN, NOTIN (the operator IN on integers takes aninteger and a set of integers and evaluates to “true” if the integer isin the set, the operator IN on strings is similarly defined, and theoperator NOTIN is the negation of IN).

In addition to built-in conditions, users of system 110 may declarecustom evaluation functions, which are customer-defined conditions.System 110 may provide an Application Programming Interface (API) forinvoking customer-supplied code to evaluate custom evaluation functions.For example, an evaluation function could access a remote database tovalidate certain properties of the object. Another evaluation functioncould invoke an external server to authenticate the subject.

Now referring to the FIG. 2 embodiment, policy manager 210 preferablyincludes a management station program 212 to operate policy manager 210,a distributor program 214 to distribute local client policies toclients, a logger program 216 to track authorization requests, and adatabase management system (DBMS) 218 to maintain policy data files.Policy manager 210 also includes an audit log data file 220 to recordauthorization requests, an optimized policy data file 222, an enterprisepolicy data file 224, an administrative policy data file 226, and alocal administrative policy data file 228. The contents and operation ofpolicy manager 210 are further discussed below in conjunction with FIGS.4, 8, 9, 10, 11, and 12.

Referring now to FIG. 3, a block diagram of one embodiment fornon-volatile memory 138, located within client 116 of FIG. 1, is shown.In the FIG. 3 embodiment, non-volatile memory 138 preferably includes anapplication guard 310 that grants or denies access to various componentsof client 116, as specified by a pre-determined policy. For example,various components of client 116 can include applications, data, and/orobjects. In the FIG. 3 embodiment, application guard 310 preferablyincludes at least one application 312, an authorization library program314, an authorization engine program 316, and a local client policy 318.The contents and operation of application guard 310 are furtherdiscussed below in conjunction with FIGS. 5, 13, and 14.

Referring now to FIG. 4, a block diagram of one embodiment for policymanager 210, located within non-volatile memory 124 in FIG. 2, is shown.In the preferred embodiment, policy manager 210 allows system users toimplement, analyze, edit and update a centrally-managed security policyor enterprise policy 224. In the FIG. 4 embodiment, policy manager 210preferably includes a management console or management station 212, adatabase management system 218, an audit facility or logger 216, and adistributor 214.

In the FIG. 4 embodiment, management station 212 preferably includes agraphical user interface (GUI) 410 for creating or customizing rules bysystem users. Management station 212 supports concurrent ruledevelopment by multiple users. Each policy rule preferably includes fourbasic components: 1) an object that is to be protected; 2) an accessright or privilege; 3) a global or local user to which the privilegeapplies; and 4) conditions under which the privilege is granted ordenied, including built-in access criteria such as time of day orlocation, as well as custom-defined access criteria.

Graphical user interface (GUI) 410 provides a user-friendly set of menuoptions or management services 412 to fully operate the policy manager.Programs controlled by the menu options may include navigation 414,search 416, distribution 418, edit 420, query 422, and log viewer 424.The operation of these programs are further discussed below inconjunction with FIGS. 8, 9, 10, 11, and 12. As an alternative to theGUI, the management services can be operated from an application throughan API that allows programs to perform the same functions as a humanoperator. In the preferred embodiment, management station also includesan application guard 426 to allow only authorized administrators tooperate management station 212. Local administrative policy 228 providesa set of policy rules specifying which users are authorized to accessmanagement station 212.

After the policy rules are created or modified using management station212, they may then be distributed to appropriate clients 116. Managementstation 212 includes a communication interface 434 in order to passinformation between various other components in system 110.

Prior to when the policy rules are distributed, a parser/type checker428 preferably reviews and reconstructs the policy rules to make surethat they are syntactically and semantically correct according to apredefined policy language. The policy rules pass through a databaselayer (DB layer) 430 and an open database connectivity layer (ODBC) 432before being stored as enterprise policy 224. DB layer 430 formats thepolicy rules into standard database storage tables, and ODBC 432provides a common interface to various vendor-specific databases.

Enterprise policy 224 is then passed to distributor 214. An optimizerprogram 436 within distributor 214 determines which application guard310 needs to receive which policy rules. A differ program 438 determineswhat type of changes were made to optimized policy 222, and thendistributes only the changed policy rules or local client policy 318 tothe appropriate application guards 310 through an ODBC layer 440 and acommunication interface 442, which enforce access control to localapplications and data.

Since the application guards 310 can be distributed among variousclients 116, and each application guard 310 has its own specific localclient policy 318, the system provides scalability.

Distributor 214 may also be used to optimize administrative policy 226into an optimized administrative policy or local administrative policy228 for use with application guard 426 in management station 212.

Referring now to FIG. 5, a block diagram of one embodiment ofapplication guard 310, located within non-volatile memory 138 in FIG. 3,is shown. Application guard 310 may be distributed on clients 116throughout an enterprise, and is designed to reside along with each ofthe protected applications having an associated application guard 310.

Application guard 310 supports transactional access control by allowingan application to be aware of the authorization service and to makeauthorization requests at each and every user interaction, data request,or business-level transaction. In addition, the design and integrationof application guard 310 is fundamental to providing access control tobusiness-level objects within an application since the authorizationservices have visibility to those named policy objects within theapplication.

In the FIG. 5 embodiment, application guard 310 is preferably integratedinto application 312 through a high-level application programminginterface (API) or authorization library 314 that allows application 312to request authorization services as needed through an application guardinterface 512. Typically, this can be done very quickly by includingauthorization requests at key points in application 312 for control userinteraction or database access so that each interaction is protectedwith a minimum of development.

In the FIG. 5 embodiment, an authorization request is processed byauthorization engine 316. A parser/type checker 514 parses local clientpolicy 318 and stores the parsed local client policy in RAM 136. Anevaluator 516 then determines whether the authorization request shouldbe granted or denied by evaluating the authorization request with theparsed local client policy in RAM 136. Plug-ins 522 in authorizationengine 316 allow for additional capabilities to process and evaluateauthorization requests based on customized code. Each authorizationrequest is then recorded in an audit log 518 and transmitted to logger216 via a communication interface 520.

Users have the option of implementing application guard 310 locally toapplication 312, as a service running on the same system as application312, or as a remote authorization service through a remote procedurecall to another server. The advantage of the latter design would be tooffload the application server from handling authorization services orallowing a single authorization server to handle a multiple number ofapplications. A local implementation would provide maximum performanceand minimize any network traffic overhead.

As seen in FIG. 5, application guard 310 includes an application guardinterface 512 coupled to an application 312 for requesting access tosecurable components. Application guard 310 also includes at least oneauthorization engine 316 for evaluating requests from application guardinterface 512 as specified by local client policy 318. Multipleauthorization engines 316 can be used for added performance andreliability. Furthermore, application guard interface 512 can be locatedon a client computer, while authorization engine 316 and local clientpolicy 318 can be located on a client server.

The application guard authorization service of the present inventionintroduces virtually no performance overhead to an existing application312. The policy rules developed at policy manager 210 are compiled intoan optimized form before being distributed to the target applicationguards 310. This optimized form only distributes attributes relevant tothat application guard 310, so that access requests may be evaluated byreviewing only a few rules rather than frequently analyzing thepotentially large policy rule base.

Referring back to FIG. 4, logger 216 may then advantageously receive aclient audit log 450 through a communication interface 452 and an ODBC454 from authorization engine 316 (FIG. 5). Client audit log 450 is thenformatted by message processing 456 before being stored in audit log220. Audit log 220 may then be monitored via log viewer 424 inmanagement station 212.

Referring now to FIG. 6, a block diagram of one embodiment of a policyloader 610 is shown. In the FIG. 6 embodiment, policy rules may beentered one at a time into enterprise policy database 224 via managementstation 212 (FIG. 4), or the policy rules may alternatively be loaded asa batch process via policy loader 610. Policy loader 610 is anadditional utility that bulk loads an existing set of policy rules intoenterprise policy database 224. An existing set of policy rules may beentered into policy loader 610 via input 612. A parser/type checker 614then preferably reviews and reconstructs the policy rules to make surethat they are syntactically and semantically correct according to apredefined policy language. The policy rules may then be passed througha DB layer 616 and an ODBC 618 before being stored in enterprise policydatabase 224.

Referring now to FIG. 7, a flowchart of method steps to configure asystem in accordance with one embodiment of the present invention isshown. Initially, in step 710, a system administrator installs policymanager 210 on a server 112. The installation may include managementstation 212, distributor 214, logger 216, and DBMS 218. After all thecomponents of policy manager 210 have been installed, the systemadministrator then enters a set of policy rules. In step 712, theadministrator can decide whether to use policy loader 610, or to usemanagement station 212 to enter policy rules. If the systemadministrator decides to use management station 212, then at step 714,policy rules are entered using edit function 420. However, if policyloader 610 is used, then at step 716, policy rules are entered into afile, and at step 718, the file of policy rules passes to policy loader610.

Next, in step 720, the system administrator installs application guards310 onto client systems 116, as well as installing local client policies318 onto client systems 116. Then at step 722, the system administratorregisters plug-ins 522 into application guards 318 to allow foradditional capabilities in order to process authorization requests basedon customized code.

Referring now to FIG. 8, a flowchart of one embodiment to manage policyunder management services 412 in management station 212 is shown. Inorder to allow for a complex set of policy rules, a number of differentfunctionality features are incorporated into system 110 to facilitateimplementation and management.

In the FIG. 8 embodiment, at step 810, an authorized administrator logsin to policy manager 210. Next, in step 812, the authorizedadministrator chooses between administrative mode or enterprise mode.The administrative mode allows the system administrator to manageadministrative policy 226, and the enterprise mode allows the systemadministrator to manage enterprise policy 224. The system administratoris then presented with six menu options including navigate tree 814,analyze policy 816, edit policy 818, distribute policy 820, view auditlog 822, and exit 824. The features of navigate tree 814, analyze policy816, edit policy 818, and distribute policy 820 are described in moredetail through FIGS. 9, 10, 11, and 12, respectively. View audit log 822is a security feature that allows an administrator to view and track allauthorization requests that have occurred at any application guards 310connected to system 110. The system administrator can choose any of themenu options, or at step 824 the system administrator may then exit thesystem.

Referring now to FIG. 9, a flowchart of one embodiment of menu optionnavigate tree 814 in management station 212 is shown. Navigate tree 814provides a set of options for an administrator to add, delete, and/ormodify features on server 112 or client 116. The features that anadministrator may add, delete, and/or modify include global users 910,global roles 912, directories 914, local roles 916, local users 918,applications 920, application guards 922, and declarations 924. At step926, the system administrator may then exit from navigate tree 814.

Referring now to FIG. 10, a flowchart of one embodiment of menu optionanalyze policy 816 in management station 212 is shown. Analyze policy816 preferably allows an authorized user to analyze and view rules andpolicies within enterprise policy 224. At step 1010, the user has anoption to search rules, or at step 1012 to query policy. When searchrules is selected, a search can be made for all the grant rules or allthe deny rules pertaining to a particular user. When query policy isselected, a search can be made on who is granted or denied whatprivilege on which objects under what conditions.

After analyzing and viewing rules or policies, at step 1014 the systemadministrator may exit from analyze policy 816.

Referring now to FIG. 11, a flowchart of one embodiment of menu optionedit policy 818 in management station 212 is shown. Edit policy 818allows an authorized user to add, delete, and/or modify enterprisepolicy 224 features. The features that may be edited include rule sets1110, access 1112, privilege 1114, objects 1116, user/role 1118, andattributes 1120. At step 1122, the system administrator may then exitedit policy 818.

Referring now to FIG. 12, a flowchart of one embodiment of method stepsof menu option distribute policy 820 is shown. After enterprise policy224 has been initially entered or modified in any way, the modifiedfeatures of enterprise policy 224 may then be distributed to appropriateapplication guards 310. At step 1210, upon selecting the distributepolicy option, distributor 214 optimizes enterprise policy 224. Then atstep 1212, differ 438 preferably computes any difference between thenewly optimized policy and optimized policy 222. At step 1214, the newlyoptimized policy is then published as optimized policy 222 in DBMS 218.Next, at step 1216, only the changed portions of optimized policy 222are committed to appropriate application guards 310. At step 1218,application guards 310 receive the changed policy, and then at step1220, application guards 310 merge the changed policy into local clientpolicy 318. Next at step 1222, new local client policy 318 is activatedto work with application guard 310.

Referring now to FIG. 13, a flowchart of one embodiment of method stepsfor client access authorization is shown. The FIG. 13 example for usinga standard application guard 310 by a user begins with a user requestingaccess to a securable component protected by an application guard 310.In step 1310, application guard 310 constructs and issues anauthorization request. At step 1312, the authorization request isevaluated by application guard 310 according to its local client policy318 to determine whether to allow or deny the authorization request. Atstep 1314, audit 518 then records the authorization request in audit log450. Next, at step 1316, if there is an error in the authorizationrequest, or if the request is not valid, then at step 1318 the user isdenied access. However, if the authorization request is valid, then atstep 1320 it is determined whether access should be granted. If theevaluated authorization request does not deny access for the user, thenat step 1322 access is allowed. If the evaluated authorization requestdenies access for the user, then at step 1324 access is denied.

Referring now to FIG. 14, a flowchart of one embodiment of method stepsto evaluate an authorization request from an application guard 310 isshown. In order to evaluate an authorization request at applicationguard 310, in step 1420, evaluator 516 first searches any deny rules inlocal policy 318. At step 1412, if evaluator 516 finds any deny rules,then at step 1414, an evaluation is performed on any constraints on thedeny rules. If, at step 1416, the evaluation finds presently validconstraints on the deny rules, then at step 1418 access is denied.However, if at step 1416, the evaluation finds that the constraints onthe deny rules are not presently valid, or if no deny rules are found inforegoing step 1412, then at step 1420, a search of grant rules isperformed. If no grant rules are found at step 1422 that would allowaccess for the user, then at step 1418, access is denied. If in step1422 grant rules are found, then at step 1424 an evaluation is performedon any constraints in the grant rules. If the evaluated constraint ispresently valid, then at step 1426, a true value is passed, and at step1428 access is allowed. However, if the evaluated constraint is notpresently valid, then at step 1426, a false value is passed, and at step1418 access is denied.

The invention has been explained above with reference to a preferredembodiment. Other embodiments will be apparent to those skilled in theart in light of this disclosure. For example, the present invention mayreadily be implemented using configurations other than those describedin the preferred embodiment above. Additionally, the present inventionmay effectively be used in conjunction with systems other than the onedescribed above as the preferred embodiment. Therefore, these and othervariations upon the preferred embodiments are intended to be covered bythe present invention, which is limited only by the appended claims.

1. A system for maintaining security in a distributed computingenvironment, comprising: a policy manager located on a server tomaintain policy data files and distribute local security policies to aplurality of clients; and a plurality of application guards, whereineach application guard is located at one of the plurality of clients tomanage access by individual transactions to at least one applicationassociated with the application guard, wherein the application guardcontrols access to the application based on a local security policyreceived from the policy manager, wherein the application guard receivesan authorization request including a subject, an object and a privilegeand evaluates said request by matching the rules received from thepolicy manager to said subject, said object and said privilege in orderto control access to said application associated with the applicationguard.
 2. The system of claim 1 wherein: the policy manager deriveslocal security policies from a global security policy, the globalsecurity policy includes a plurality of rules applicable to allapplication guards in the system.
 3. The system of claim 2 wherein: thepolicy manager optimizes the global security policy into an optimizedform, wherein the optimized form only distributes attributes relevant toa specific application guard.
 4. The system of claim 1 wherein: thepolicy manager computes any differences caused by a modification on thesecurity policy and commit only the changed portion of the securitypolicy to an appropriate application guards.
 5. The system of claim 1wherein: the policy manager supports concurrent rule development bymultiple users.
 6. The system of claim 1 wherein: the policy managertracks and record authorization requests.
 7. The system of claim 1wherein: the policy manager is associated with an application guard toallow only authorized administrator to access and operate the policymanager.
 8. The system of claim 1 wherein: the policy manager reviewsand reconstructs policy rules to make sure the policy rules aresyntactically and semantically correct to a predefined policy language.9. The system of claim 1 wherein: the policy manager determines whichapplication guard needs to receive which policy rules.
 10. The system ofclaim 1 wherein: the application guard is integrated into theapplication associated with the application guard.
 11. The system ofclaim 1 wherein: the application guard evaluates the authorizationrequest against a stored local security policy.
 12. The system of claim1 wherein: the application guard is associated with plug-ins to allowfor additional capabilities to process and evaluate the authorizationrequest based on customized code.
 13. The system of claim 1 wherein: theapplication guard is implemented as a remote authorization servicethrough a remote procedure call to another server.
 14. The system ofclaim 1 wherein: the application guard uses multiple authorizationengines to add performance and reliability.
 15. The system of claim 1,further comprising: an enterprise policy database that allows a user toenter policy rules one at a time.
 16. The system of claim 16, furthercomprising: a policy loader to bulk load a existing set of policy rulesinto the enterprise policy database.
 17. A system for maintainingsecurity in a distributed computing environment, comprising: a policymanager located on a server to maintain policy data files and distributelocal security policies to a plurality of clients, wherein the policymanager operates to derive local security policies from a globalsecurity policy, the global security policy includes a plurality ofrules applicable to one or more of the plurality of clients; organizethe global security policy into an optimized form, wherein the optimizedform only distributes attributes relevant to a specific client; computeany differences caused by a modification on the global security policyand commit only the changed portion of the global security policy to aspecific client;
 18. A system for maintaining security in a distributedcomputing environment, comprising: a plurality of application guards,wherein each application guard is located at one of a plurality ofclients to manage access by individual transactions to at least oneapplication associated with the application guard, wherein theapplication guard controls access to the application based on a localsecurity policy received from a policy manager, wherein the applicationguard receives an authorization request including a subject, an objectand a privilege and evaluates said request by matching the rulesreceived from the policy manager to said subject, said object and saidprivilege in order to control access to said application associated withthe application guard.